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Abstract — Scheme uses garbage collection for heap memory 
management. Ideally, garbage collectors should be able to reclaim 
all dead objects, i.e. objects that will not be used in future. 
However, garbage collectors collect only those dead objects that 
are not reachable from any program variable. Dead objects that 
are reachable from program variables are not reclaimed. 

In this paper we describe our experiments to measure the 
effectiveness of garbage collection in MIT/GNU Scheme. We 
compute the drag time of objects, i.e. the time for which an 
object remains in heap memory after its last use. The number of 
dead objects and the drag time together indicate opportunities 
for improving garbage collection. Our experiments reveal that 
up to 26% of dead objects remain in memory. The average drag 
time is up to 37% of execution time. Overall, we observe memory 
saving potential ranging from 9% to 65%. 



I. Introduction 

Garbage collection is an attractive alternative to manual 
memory management because it frees the programmer from 
the responsibility of keeping track of object lifetimes. This 
makes programs easier to design, implement, understand and 
maintain. Ideally, a garbage collector should be able to reclaim 
all dead objects, i.e. objects that will not be used in future. 
However, this is not possible because garbage collectors con- 
servatively approximate the liveness of an object by its reach- 
ability from a predefined set of variables called root variables 
(typically the set of variables on the program stack). Garbage 
collectors cannot distinguish between live reachable objects 
from dead reachable objects. Hence they collect unreachable 
objects only as these objects are guaranteed to be dead. This 
means many dead objects are left uncollected, a fact that has 
been confirmed by empirical studies for various languages 
hke Haskell [10] and Java [12]-[14]. Our experiments for 
MIT/GNU Scheme reveal that up to 26% of dead objects 
remain in memory, with dead objects remaining in memory 
for up to 37% of execution time. Memory saving potential 
ranges from 9% to 65%. 



(let ( (X (list ...))) 
(let loop ( (y x) ) 
(if (null? y) 
' 
(begin 

(. . . (car y) . 
(loop (cdr y) 



process the head 



(a) A program traversing a linked list. 




(b) Memory graph at the beginning of 
the second iteration of the loop. 



Fig. 1. The Motivational Example. 



it cannot be collected by garbage collector as it is reachable 
from the variable x. Similarly, object O2 is unused after second 
iteration of the loop, O3 after third iteration, and so on. All 
of these objects, though dead, will be garbage collected only 
after the variable x goes out of scope (i.e. at the end of the 
outer let loop.) If x is nullified after its last use (line 2, 
first iteration of loop) the objects may be collected whenever 
garbage collection is invoked after their last use, even though 
x remains in scope. 



A. A Motivational Example 

Figure [Tfa) shows a program that traverses a singly linked 
list. Figure [TJb) shows the memory graph at the end of first 
iteration of the loop in the program. The object Oi in the 
memory is unused after the first iteration of the loop. However, 

* Supported by Infosys Technologies Limited, Bangalore, under Infosys 
Fellowship Award. 



B. Baclcground 

Figure |2] shows the important events in the life of a heap 
object: creation, use, and garbage collection. The interval from 
the time of last use to the time of garbage collection is called 
the drag time (S) and the object is called a dead object [10], 
[12]-[14]. If an object is never used after creation, its drag time 
is the interval between its creation time and its collection time. 
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drag time((5) 




creation last use becomes garbage 

unreachable collected 
time 

Fig. 2. Events in the life of an object 



A large drag time indicates that the object was reachable, and 
hence ignored by garbage collector, long after its last use. 

The number of dead objects and the drag time is a measure 
of improvement opportunities in garbage collection and give 
us an upper bound on the number of objects that could be 
collected over the ones collected by garbage collector The 
upper bound is for a particular execution path of program. 
There may be no algorithm that can collect all the dead objects. 

The drag time of an object can be divided into two com- 
ponents: (1) (5|-ch, the interval between the last use of the 
object and the time when it becomes unreachable, and (2) 
Sgc, the interval between the time when the object becomes 
unreachable and the time when it is collected by garbage 
collector S^q^ depends upon the program but is independent of 
the garbage collector, whereas Sgc depends heavily upon the 
garbage collector — algorithm used, frequency of invocation, 
and time of invocation. For example, for a reference count 
based garbage collector, 5gc is always for all objectfl 
For mark and sweep or copying collector, SgQ for an object 
depends upon the time when the garbage collector gets invoked 
after the object becomes unreachable. 6gc can typically be 
reduced by increasing the frequency of garbage collection (at 
the expense of slowing down the real computation). 

C. Organization 

The rest of this paper is organized as follows: In Section Ull 
we describe our setup to carry out the experiments and the 
benchmark programs used for measurements. Section Hill dis- 
cusses the results of the experiments. Section |IV] describes the 
research done by others in related areas. Section [V] concludes 
the paper and provides directions for future work. 

II. Experimental Setup 

In our experiments we measure the value of S^q^, which 
is the characteristic of the program only and independent of 
the garbage collector, and hence independent of the Scheme 
implementation. We approximate Sf^f^ by 6 by forcing garbage 
collector to be invoked at a very high frequency, thereby 
ensuring that 6gc = 0. However, this technique does not work 
for incremental or generational garbage collectors, because 
these do not scan all objects in memory for every cycle. 
Therefore, even after an object has become unreachable, it 
may or may not be collected by next garbage collection cycle, 
resulting in a non-zero Sgc- 



We have used MIT/GNU Schem^ as it uses a simple 
copying based garbage collector, which is neither incremental 
nor generational. It is also easy to modify the implementation 
to invoke garbage collector at a very high frequency. 

We record the statistics associated with pairs and vectors 
only, ignoring all other constructs (e.g. strings) that create 
objects in heap. Collecting statistics for all constructs is 
difficult as (a) it slows down the experiments considerably, 
and (b) the amount of statistics generated is overwhelming — 
even for moderate size benchmarks, the execution goes out 
of memory. This restriction is not that bad because previous 
studies have shown that cons cells and vectors account for 
most of the space as well number of objects allocated in typical 
LISP programs [ [16], Section 3.7.1]. 

We associate a structure with every object under consid- 
eration to record the creation time and the most recent use 
time. Whenever garbage collector collects an object, its data is 
written to a log file along with the garbage collection time. The 
log file thus generated is post-processed to generate statistics. 
Section Hl-AI and Section Hl-BI describe the process in detail. 

A. Generating Data 

We associate a structure (GC_structure) to record the 
creation time (Create_time) and the most recent use time 
(Use_time) with every object under consideration. The object 
address is used as key for GC_structure. GC_structure 
also contains a flag (GC_f lag) to tell whether the correspond- 
ing object was collected by the current garbage collection or 
not. Scheme primitives and procedures are modified to update 
the fields of GC_structure. We describe how this is done 
for primitives that operate on pairs (or lists). Similar changes 
are applied to primitives for vectors too. 

• Creation: In Scheme, pairs are created using 
primitives, e.g. cons, list, vector->list, 
string->list. These primitives are modified to 
create the GC_structure(s) corresponding to the new 
pair(s) created, and populate the Create_time, while 
Use_time is set to an invalid value (-1). 

• Use: Primitives like car, cdr, set-car ! , set-cdr ! 
including predicates like null?, pair?, number? are 
considered as use of their argument and are modified to 
update Use_time of corresponding GC_structure. If 
an object is never used, its Use_time remains -1. 

• Garbage collection: Garbage collector in MIT/GNU 
Scheme is a copying collector. Before actual garbage 
collection, we reset the GC flag in all GC_structures. 
Whenever an object is copied from working memory 
to free memory, corresponding GC_flag is set, and 
its new address is copied into the key. At the end of 
garbage collection, all GC_structures are scanned. If 
GC_f lag is false, meaning the object was not copied to 
free memory, than the object is assumed to be collected 
by garbage collector. For all such objects, we write the 
data in GC_structures to a log file along with the 
garbage collection time. Also, at program termination. 



Ignoring objects that are part of cycle. 



^Release 7. 7. 90.+, from |http : / / ftp, gnu ■ org/gnu/mit- scheme /snapshot ■ p^ 
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Benchmark 


Description 


silex 


Lexical analyzer generator [4] 


lair 


An LALR(l) parser generator [6] 


eopl 


Code in Chapter 7 of Essentials of Programming 




Languages [5] 


prolog 


Interpreter for pure Prolog [3] 


sudoku 


Sudoku [15] puzzle solver [9] 


cipher 


Program [1] to decode substitution cipher [2] 



TABLE I 
The benchmarks 



Benchmark 


Reachable 


Live 


Potential 




Object 


Object 


Savings 




Integral 


Integral 


% 


silex 


409442730 


141309450 


65.48 


lair 


109380 


58450 


46.56 


eopl 


373865300 


217799490 


41.74 


prolog 


175096720 


72172390 


58.78 


sudoku 


496456510 


450879850 


9.18 


cipher 


208383570 


184187520 


11.61 



TABLE II 

Space time product for reachable obiects and live obiects 



data in GC_structures of all the objects remaining in 

heap is written to the log file. 
Scheme runtime libraries are forced to use these modified 
primitives. We trigger garbage collection at every 10 millisec- 
onds. The benchmarks are run in this modified environment 
to generate data in the log file. 

B. Reporting Data 

The log files generated by running the benchmark programs 
are processed to generate statistics. In our experiments 

> We compare the number of dead objects with the number 
of allocated objects. 

• We compare the average drag time of objects and maxi- 
mum drag time over all the objects with the total runtime 
of the program. 

• We record the distribution of drag times of objects as a 
percentage of total runtime. 

Potential savings in memory is estimated by measuring the 
space time product for dead objects as a percentage of space 
time product for all allocated objects. 

C. Benchmarks 

Our benchmark programs are described in Table U The 
programs range from code (eopl) from standard text-book 
Essentials of Programming Languages [5] to the programs 
(cipher and sudoku) by first year undergraduates, silex 
and lair are run with one test case each, while eopl, 
prolog, sudoku and cipher are run with multiple test 
cases each. The benchmarks and test cases can be obtained 
from [7]. 

III. Results 

In this section we describe the results of our experiments. 

A. Reachable vs. Live Objects 

Figure [3] plots reachable objects and live objects against 
time. The difference between the two lines gives the number 
of reachable but dead objects. All the graphs show a significant 
number of dead objects. 

The graphs of prolog, sudoku and cipher contain 
many crests and troughs, while the graphs for silex, lair 
and eopl are relatively smooth. Our conjecture is that this 
is because prolog, sudoku and cipher use backtracking 



algorithms, and the troughs correspond to the transitions 
between successive backtracking phases. To validate our con- 
jecture, we experimented with sudoku. We used 3 different 
test cases — the first test case had only one cell unfilled so 
that no backtracking was required by sudoku solver The 
second test case had very few unfilled cells so that a little 
amount of backtracking was involved, while the third test 
case was a very hard puzzle that involved high amount of 
backtracking. The results are shown in Figure HI We can see 
that, for the third test case, the number of crest-trough pairs 
is too high as compared to other cases. Also, since sudoku 
solver's algorithm is mainly a backtracking algorithm with a 
few heuristics, runtime of the test cases increases with the 
level of difficulty (backtracking). 

In eopl there is an initial burst where the reachable 
memory is very high. This corresponds to the phase where all 
the test cases are loaded into Scheme. For our experiments, 
we ran three interpreters corresponding to the code given in 
Chapter 7 of [5]. Small crests in plot of reachable objects 
(and troughs in plot of live objects) in eopl correspond to 
transition from one interpreter to other 

To estimate the memory savings, we compute the space- 
time product for reachable objects and that for live objects 
by computing the area under respective plots (see Table |ll|. 
The potential of saving ranges from 9% to 65% for our 
benchmarks. 

B. Number of Allocated Objects vs. Dead Objects 

Figure|5] shows total number of objects allocated vs. number 
of dead objects. Even though the percentage of dead objects 
is very small (less than 5%) for sudoku and eopl, there is 
still significant potential for memory savings because the drag 
time of these objects is large. This is described in details in 
next section. 

C. Drag vs. Runtime 

In Table Unl we show how drag time of objects compare with 
the total runtime for a given program. Note that for silex, 
eopl, prolog, and sudoku, the maximum drag time is very 
close to the total runtime. This indicates presence of objects 
that are created near the beginning of the program and remain 
unused throughout the execution. 

Figure |6] shows the distribution of dead times of objects as 
percentage of runtime of the program. In all the benchmarks. 
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lair 
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22000 44000 66000 88000 11000C 
eopi 
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20000 
prolog 



30000 



4000C 




16000 32000 48000 64000 80000 96000 
sudoku 




8000 12000 16000 20000 24000 28000| 
cipher 



X axis indicates measurement instants in milliseconds. Y axis indicates number of heap objects. 
Solid line represents reachable objects. Dashed line represents live objects. 



Fig. 3. Reachable objects vs. live objects 




500 1000 1500 2000 250C 
sudoku 

No backtracking 




1000 2000 3000 4000 5000 600C 
sudoku 

Little backtracking 




5000 10000 15000 20000 25000 30000 3500C 
sudoku 

High backtracking 



X axis indicates measurement instants in milliseconds. Y axis indicates number of heap objects. 
Solid line represents reachable objects. Dashed line represents hve objects. 



Fig. 4. Effect of backtracking on sudoku solver 



most of the dead objects are in the range 0-50% of total 
runtime, lair and cipher do not have any objects towards 
higher percentages. On the other hand, silex, eopl and 
sudoku have a large number of objects that have a significant 
drag time of 95-100%. These objects contribute significantly 
to the space time product (Table Collecting such objects 
will yield high memory savings. 



IV. Related Work 

Similar experiments have been done to measure the effec- 
tiveness of garbage collection in different language implemen- 
tations, e.g. Haskell [10], Java [12]-[14]. Our definitions and 
measurement methodologies are based on the standards from 
previous work. 
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Figures in parenthesis denote the percentage of dead objects with respect to allocated objects. 



Fig. 5. Allocated objects vs. dead objects 



Benchmark 


Runtime 


Maximum Drag 


Average Drag 


silex 


27950 


27110 (96.99) 


7928.94 (28.36) 


lair 


480 


250 (52.08) 


179.96 (37.49) 


eopl 


109060 


108620 (99.59) 


5403.56 (4.95) 


prolog 


39970 


39700 (99.32) 


2419.81 (6.05) 


sudoku 


82730 


82610 (99.85) 


2229.23 (2.69) 


cipher 


27250 


13440 (49.32) 


630.25 (2.31) 



All times are in milliseconds. 

Figures in parenthesis denote percentage value witii respect to runtime. 

TABLE III 
Statistics of dead objects 



KBDB [11], a heap inspector for Scheme programs, relies 
on user interaction to inspect heap usage at different points 
during the execution of program. Typically, the heap is in- 
spected before and after evaluation of some expression to 
estimate the memory leaked by that expression. This approach 
is orthogonal to our approach of using dead object information 
to detect memory leak. 

V. Conclusions and Future Work 

Our experiments show that for Scheme, at any given time, 
there is a significant number of reachable objects that are 
not live. Also, a large number of such objects remain in 
memory for a long duration. Garbage collection for Scheme 
can improve significantly if such objects can be identified and 
made unreachable at the earliest using automatic techniques. 

In, our earlier work [8], we have shown that for imperative 
languages like Java, the number of reachable dead objects can 
be reduced by automatically identifying and nullifying dead 
memory links. We are extending that work to be applicable to 
functional languages. The work reported in this paper is the 
first step towards that direction. 
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